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RFC 8697 

Path Computation Element Communication Protocol 
(PCEP) Extensions for Establishing Relationships 
between Sets of Label Switched Paths (LSPs) 


Abstract 


This document introduces a generic mechanism to create a grouping of Label Switched Paths 
(LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to 
define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as 
configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active 
and passive modes) and the stateless PCE. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc8697. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 
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This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


[RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP 
enables communication between a Path Computation Client (PCC) and a PCE, or between a PCE 
and another PCE, for the purpose of the computation of Multiprotocol Label Switching (MPLS) as 
well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) 
characteristics. 
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[RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and 
across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State 
Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE 
control of timing and sequence of path computations within and across PCEP sessions. The 
operational model whereby LSPs are initiated from the PCE is described in [RFC8281]. 


[RFC4872] defines the RSVP ASSOCIATION object, which was defined in the context of GMPLS- 
controlled LSPs to be used to associate recovery LSPs with the LSP they are protecting. This 
object also has broader applicability as a mechanism to associate RSVP state. [RFC6780] describes 
how the ASSOCIATION object can be more generally applied by defining the Extended 
ASSOCIATION object. 


This document introduces a generic mechanism to create a grouping of LSPs. This grouping can 
then be used to define associations between sets of LSPs or between a set of LSPs and a set of 
attributes (such as configuration parameters or behaviors), and it is equally applicable to the 
stateful PCE (active and passive modes) and the stateless PCE. The associations could be created 
dynamically and conveyed to a PCEP peer within PCEP, or they could be configured manually by 
an operator on the PCEP peers. Refer to Section 3.3 for more details. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


2. Terminology 


This document uses the following terms defined in [RFC5440]: 


e PCC 

e PCE 

¢ PCEP Peer 

e Path Computation Request (PCReq) 
e Path Computation Reply (PCRep) 

e PCEP Error (PCErr) 


This document uses the following terms defined in [RFC8051]: 


e Stateful PCE 

e Active Stateful PCE 
e Passive Stateful PCE 
e Delegation 
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This document uses the following terms defined in [RFC8231]: 


e LSP State Report (PCRpt) 
° LSP Update Request (PCUpd) 
e State Timeout Interval 


This document uses the following terms defined in [RFC8281]: 


e PCE-initiated LSP 
e LSP Initiate Request (PCInitiate) 


3. Architectural Overview 


3.1. Motivations 


A stateful PCE provides the ability to update existing LSPs and to instantiate new ones. There are 
various situations where several LSPs need to share common information. For example, to 
support PCE-controlled make-before-break, an association between the original path and the 
reoptimized path is desired. Similarly, for end-to-end protection, an association between working 
and protection LSPs is required (see [PCE-PROTECTION)). For diverse paths, an association 
between a group of LSPs could be used (see [PCE-DIVERSITY]). Another use for an LSP grouping 
would be to apply a common set of configuration parameters or behaviors to a set of LSPs. 


For a stateless PCE, it might be useful to associate a PCReq message to an association group, thus 
enabling it to associate a common set of policies, configuration parameters, or behaviors with the 
request. 


Some associations could be created dynamically, such as an association between the working and 
protection LSPs of a tunnel, whereas some associations could be created by the operator 
manually, such as a policy-based association where the LSP could join an operator-configured 
existing association. 


Rather than creating separate mechanisms for each use case, this document defines a generic 
mechanism that can be reused as needed. 


3.2. Relationship to the SVEC List 


Note that [RFC5440] defines a mechanism for the synchronization of a set of PCReq messages by 
using the SVEC (Synchronization VECtor) object, which specifies the list of synchronized requests 
that can be either dependent or independent. The SVEC object identifies the relationship between 
the set of PCReq messages, identified by "Request-ID-number" in the RP (Request Parameters) 
object. [RFC6007] further clarifies the use of the SVEC list for synchronized path computations 
when computing dependent requests, and it describes a number of usage scenarios for SVEC lists 
within single-domain and multi-domain environments. 
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The motivations behind the association group defined in this document and the SVEC object are 
quite different, though some use cases may overlap. PCEP extensions that define a new 
Association Type should clarify the relationship between the SVEC object and the Association 
Type, if any. 


3.3. Operational Overview 


LSPs are associated with other LSPs with which they interact by adding them to a common 
association group. Association groups as defined in this document can be applied to LSPs 
originating at the same headend or different headends. 


Some associations could be created dynamically by a PCEP speaker, and the associations (along 
with the set of LSPs) are conveyed to a PCEP peer. Whereas some associations are configured by 
the operator beforehand on the PCEP peers in question, a PCEP speaker could then ask an LSP to 
join the Operator-configured Association. Usage of dynamic and configured associations is 
usually dependent on the type of association. 


For Operator-configured Associations, the association parameters, such as the Association 
Identifier (Association ID), Association Type, and the Association Source IP address, are manually 
configured by the operator. In the case of a dynamic association, the association parameters, 
such as the Association ID, are allocated dynamically by the PCEP speaker. The Association 
Source is set as the local PCEP speaker address unless local policy dictates otherwise, in which 
case the Association Source is set based on the local policy. 


The dynamically created association can be reported to the PCEP peer via the PCEP messages as 
per the stateful extensions. When the Operator-configured Association is known to the PCEP peer 
beforehand, a PCEP peer could ask an LSP to join the Operator-configured Association via the 
stateful PCEP messages. 


The associations are properties of the LSP and thus could be stored in the LSP state database. The 
dynamic association exists as long as the LSP state exists. In the case of PCEP session termination, 
the LSP state cleanup MUST also take care of associations. 


Multiple types of associations can exist, each with its own Association ID space. The definition of 
the different Association Types and their behaviors is outside the scope of this document. The 
establishment and removal of the association relationship can be done on a per-LSP basis. An 
LSP may join multiple association groups that have the same Association Type or different 
Association Types. 


3.4. Operator-Configured Association Range 


Some Association Types are dynamic, some are operator configured, and some could be both. For 
the Association Types that could be both dynamic and operator configured and use the same 
Association Source, it is necessary to distinguish a range of Association IDs that are marked for 
Operator-configured Associations, to avoid any Association ID clashes within the scope of the 
Association Source. This document assumes that these two ranges are configured. 
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A range of Association IDs for each Association Type (and Association Source) is kept for the 
Operator-configured Associations. Dynamic associations MUST NOT use the Association ID from 
this range. 


This range, as set at the PCEP speaker (a PCC or PCE, as an Association Source), needs to be 
communicated to a PCEP peer in the Open message. A new TLV is defined in this specification for 
this purpose (Section 5). See Appendix A for an example. 


The Association ID range for sources other than the PCEP speaker (for example, a Network 
Management System (NMS)) is not communicated in PCEP, and the procedure for Operator- 
configured Association Range settings is outside the scope of this document. 


4. Discovery of Supported Association Types 


This section defines PCEP extensions so as to support the capability advertisement of the 
Association Types supported by a PCEP speaker. 


A new PCEP ASSOC-Type-List (Association Types list) TLV is defined. The PCEP ASSOC-Type-List 
TLV is carried within an OPEN object. This way, during the PCEP session-setup phase, a PCEP 
speaker can advertise to a PCEP peer the list of supported Association Types. 


4.1. ASSOC-Type-List TLV 


The PCEP ASSOC-Type-List TLV is OPTIONAL. It MAY be carried within an OPEN object sent by a 
PCEP speaker in an Open message to a PCEP peer so as to indicate the list of supported 
Association Types. 


The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV format defined in 
[RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, 
and a Value field. The Length field defines the length of the value portion in octets. The TLV is 
padded to 4-octet alignment, and padding is not included in the Length field (e.g., a 3-octet value 
would have a length of three, but the total size of the TLV would be 8 octets). 


The PCEP ASSOC-Type-List TLV has the following format: 


0) Al 2 3 

O E S S E E SO A S SS T RE O a A e SS A Sa 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Assoc-Type #1 l Assoc-Type #2 l 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+HHHHHH HHHH 
// // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Assoc-Type #N l padding l 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Figure 1: The ASSOC-Type-List TLV Format 
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Type: 35 
Length: N * 2 (where N is the number of Association Types). 


Value: List of 2-byte Association Type code points, identifying the Association Types supported 
by the sender of the Open message. 


Assoc-Type (2 bytes): Association Type code point identifier. IANA manages the "ASSOCIATION 
Type Field" code point registry (see Section 7.4). 


4.1.1. Procedure 


An ASSOC-Type-List TLV within an OPEN object in an Open message is included by a PCEP 
speaker in order to advertise a set of one or more supported Association Types. The ASSOC-Type- 
List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the 
PCEP session MUST be rejected with Error-Type 1 and Error-value 1 (PCEP session establishment 
failure / Reception of an invalid Open message). As specified in [RFC5440], a PCEP peer that does 
not recognize the ASSOC-Type-List TLV will silently ignore it. 


The Association Type (to be defined in future documents) can specify if the Association Type 
advertisement is mandatory for it. Thus, the ASSOC-Type-List TLV MUST be included if at least 
one mandatory Association Type needs to be advertised, and the ASSOC-Type-List TLV MAY be 
included otherwise. For an Association Type that specifies that the advertisement is mandatory, a 
missing Assoc-Type in the ASSOC-Type-List TLV (or a missing ASSOC-Type-List TLV) is to be 
interpreted as meaning that the Association Type is not supported by the PCEP speaker. 


The absence of the ASSOC-Type-List TLV in an OPEN object MUST be interpreted as an absence of 
information in the list of supported Association Types (rather than an indication that the 
Association Type is not supported). In this case, the PCEP speaker could still use the 
ASSOCIATION object: if the peer does not support the association, it will react as per the 
procedure described in Section 6.4. 


If the use of the ASSOC-Type-List TLV is triggered by support for a mandatory Association Type, 
then it is RECOMMENDED that the PCEP implementation include all supported Association Types 
(including optional types) to ease the operations of the PCEP peer. 


5. Operator-Configured Association Range TLV 


This section defines a PCEP extension to support the advertisement of the Operator-configured 
Association Range used for an Association Type by the PCEP speaker (as an Association Source). 


A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association Range) TLV is defined. 
The PCEP OP-CONF-ASSOC-RANGE TLV is carried within an OPEN object. This way, during the 
PCEP session-setup phase, a PCEP speaker can advertise to a PCEP peer the Operator-configured 
Association Range for an Association Type. 
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The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL. It MAY be carried within an OPEN object 
sent by a PCEP speaker in an Open message to a PCEP peer. The OP-CONF-ASSOC-RANGE TLV 
format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed 
of 2 bytes for the type, 2 bytes specifying the TLV length, and a Value field. The Length field 
defines the length of the value portion in bytes. 


The PCEP OP-CONF-ASSOC-RANGE TLV has the following format: 


(0) al 2 3 
OM 2 3456. 839 O 2) e A a e S a 2342561 89 O a 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Reserved l Assoc-Type #1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 
$ 


Start-Assoc-ID #1 Range #1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| 
+ 
| 
+ 
| 
+ 
ii / 
+ 
| 
+ 
| 
+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


F 
Reserved l Assoc-Type #N 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

+ 


Start-Assoc-ID #N 
+-+- t-t- t-t ttt 


Range #N 
Gp eta St ae i ttoO 


+— +— +N $+ — +— +— H 


Figure 2: The OP-CONF-ASSOC-RANGE TLV Format 


Type: 29 
Length: N * 8 (where N is the number of Association Types). 


Value: Includes the following fields, repeated for each Association Type: 


Reserved (2 bytes): MUST be set to 0 on transmission and MUST be ignored on receipt. 


Assoc-Type (2 bytes): The Association Type (Section 7.4). The Association Types will be 
defined in future documents. 


Start-Assoc-ID (2 bytes): The "start association" identifier for the Operator-configured 
Association Range for the particular Association Type. The values 0 and Oxffff MUST 
NOT be used; on receipt of these values in the TLV, the session is rejected, and an 
error message is sent (see Section 5.1). 


Range (2 bytes): The number of associations marked for the Operator-configured 
Associations. Range MUST be greater than 0, and it MUST be such that (Start-Assoc-ID 
+ Range) does not cross the largest Association ID value of Oxffff. If this condition is 
not satisfied, the session is rejected, and an error message is sent (see Section 5.1). 
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5.1. Procedure 


A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN object in an Open 
message sent to a PCEP peer in order to advertise the Operator-configured Association Range for 
an Association Type. The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an 
OPEN object. If it appears more than once, the PCEP session MUST be rejected with Error-Type 1 
and Error-value 1 (PCEP session establishment failure / Reception of an invalid Open message). 


As specified in [RFC5440], a PCEP peer that does not recognize the OP-CONF-ASSOC-RANGE TLV 
will silently ignore it. 


The Operator-configured Association Range SHOULD be included for each Association Type that 
could be both dynamic and operator configured. For Association Types that are only dynamic or 
only operator configured, this TLV MAY be skipped, in which case the full range of Association 
IDs is considered dynamic or operator configured, respectively. Each Association Type (to be 
defined in future documents) can specify the default value for its Operator-configured 
Association Range. 


The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be interpreted as an 
absence of an explicit Operator-configured Association Range at the PCEP peer. In this case, the 
default behavior as per each Association Type applies. If the Association Source is not a PCEP 
speaker, the default value for the Operator-configured Association Range is used for the 
Association Source. 


If the Assoc-Type is not recognized or supported by the PCEP speaker, it MUST ignore that 
respective (Start-Assoc-ID + Range). If the Assoc-Type is recognized/supported but Start-Assoc-ID 
or Range is set incorrectly, the PCEP session MUST be rejected with Error-Type 1 and Error-value 
1 (PCEP session establishment failure / Reception of an invalid Open message). The incorrect 
range includes the case when the (Start-Assoc-ID + Range) crosses the largest Association ID value 
of Oxffff. 


A given Assoc-Type MAY appear more than once in the OP-CONF-ASSOC-RANGE TLV in the case 
of a non-contiguous Operator-configured Association Range. The PCEP speaker originating this 
TLV MUST NOT send overlapping ranges for an Association Type. If a PCEP peer receives 
overlapping ranges for an Association Type, it MUST consider the Open message malformed and 
MUST reject the PCEP session with Error-Type 1 and Error-value 1 (PCEP session establishment 
failure / Reception of an invalid Open message). 


There may be cases where an Operator-configured Association was configured with association 
parameters (such as an Association ID, Association Type, and Association Source) at the local 
PCEP speaker, and the PCEP session is later established with the Association Source and a new 
operator-configured range is learned during session establishment. At this time, the local PCEP 
speaker MUST remove any associations that are not in the new operator-configured range (by 
disassociating any LSPs that are part of it (and notifying the PCEP peer of this change)). If a PCEP 
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speaker receives an association for an Operator-configured Association and the Association ID is 
not in the Operator-configured Association Range for the Association Type and Association 
Source, it MUST generate an error (as described in Section 6.4). 


6. ASSOCIATION Object 


6.1. Object Definition 


Association groups and their memberships are defined using a new ASSOCIATION object. 
The ASSOCIATION Object-Class value is 40. 


The ASSOCIATION Object-Type value is 1 for IPv4, and its format is shown in Figure 3: 


0) 1 2 3 
O S A S T E Om Ole ae? E Ae om Ona e E O A ena S S ico o 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Reserved l Flags IR] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Association Type l Association ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++HHHHHHOH 
| IPv4 Association Source 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ip / 
+ + 


i Optional TLVs / 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: The IPv4 ASSOCIATION Object Format 


The ASSOCIATION Object-Type value is 2 for IPv6, and its format is shown in Figure 4: 


(0) al, 2 3 
O 25S A Oe OM Om Om Ome aren a A Ono sO mele aS 74 S S T e Om o 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Reserved l Flags IR] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Association Type l Association ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l IPv6 Association Source 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Hh Optional TLVs // 
toto toto-tititot-ta ttt a tito t ait tanta t ita t atid ita titi t oti tititact 


Figure 4: The IPv6 ASSOCIATION Object Format 


Reserved (2 bytes): MUST be set to 0 and ignored upon receipt. 


Flags (2 bytes): The following flag is currently defined: 
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R (Removal - 1 bit): When set, the requesting PCEP peer requires the removal of an LSP 
from the association group. When unset, the PCEP peer indicates that the LSP is 
added or retained as part of the association group. This flag is used for the 
ASSOCIATION object in the Path Computation Report (PCRpt) and Path Computation 
Update (PCUpd) messages. It is ignored in other PCEP messages. 


The unassigned flags MUST be set to 0 on transmission and MUST be ignored on receipt. 


Association Type (2 bytes): The Association Type (Section 7.4). The Association Types will be 
defined in future documents. 


Association ID (2 bytes): The identifier of the association group. When combined with other 
association parameters, such as an Association Type and Association Source, this value 
uniquely identifies an association group. The values Oxffff and 0x0 are reserved. The value 
Oxffff is used to indicate all association groups and could be used with the R flag to indicate 
removal for all associations for the LSP within the scope of the Association Type and 
Association Source. 


Association Source: Contains a valid IPv4 address (4 bytes) if the ASSOCIATION Object-Type is 1 
or a valid IPv6 address (16 bytes) if the ASSOCIATION Object-Type is 2. The address 
provides scoping for the Association ID. See Section 6.1.3 for details. 


Optional TLVs: The optional TLVs follow the PCEP TLV format defined in [RFC5440]. This 
document defines two optional TLVs. Other documents can define more TLVs in the future. 


6.1.1. Global Association Source TLV 


The Global Association Source TLV is an optional TLV for use in the ASSOCIATION object. The 
meaning and usage of the Global Association Source TLV are as per Section 4 of [RFC6780]. 


(0) 1 2 3 
OMERA Sato A e SOOM A Se 4 ESO Cu OOM e See Sm Ome Omo nm Ome: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
l Global Association Source 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— +— + 


Figure 5: The Global Association Source TLV Format 


Type: 30 
Length: Fixed value of 4 bytes. 
Global Association Source: As defined in Section 4 of [RFC6780]. 


6.1.2. Extended Association ID TLV 


The Extended Association ID TLV is an optional TLV for use in the ASSOCIATION object. The 
meaning and usage of the Extended Association ID TLV are as per Section 4 of [RFC6780]. 
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(0) al 2 2 

omit?” A5 6 m S 9 Oma 2S e456 7 g9 Oma S oror 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
iff Extended Association ID Hf 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 6: The Extended Association ID TLV Format 


Type: 31 
Length: Variable. 


Extended Association ID: As defined in Section 4 of [RFC6780]. 


6.1.3. Association Source 


The Association Source field in the ASSOCIATION object is set to a valid IP address to identify the 
node that originated the association. In the case of dynamic associations, the Association Source 
is usually set as the local PCEP speaker address unless local policy dictates otherwise, in which 
case the Association Source is set based on the local policy. In the case of PCE redundancy, local 
policy could set the source as a virtual IP address that identifies all instances of the PCE. In the 
case of Operator-configured Associations, the Association Source is manually configured, and it 
could be set as one of the PCEP speakers, an NMS, or any other valid IP address that scopes the 
Association ID for the Association Type. 


6.1.4. Unique Identification for an Association Group 


The combination of the mandatory fields Association Type, Association ID, and Association 
Source in the ASSOCIATION object uniquely identifies the association group. If the optional TLVs 
(Global Association Source and Extended Association ID) are included, then they MUST be 
included in combination with mandatory fields to uniquely identify the association group. In this 
document, all these fields are collectively called "association parameters". Note that the 
ASSOCIATION object MAY include other optional TLVs (not defined in this document) based on 
the Association Types. These TLVs provide "information" related to the Association Type. This 
document refers to this information as "association information". 


6.2. Relationship to the RSVP ASSOCIATION Object 


The format of the PCEP ASSOCIATION object defined in this document is aligned with the RSVP 
ASSOCIATION object [RFC6780]. Various Association Types related to RSVP association are 
defined in [RFC4872], [RFC4873], and [RFC7551]. The PCEP extensions that define new 
Association Types should clarify how the PCEP associations would work with RSVP associations 
and vice versa. 
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6.3. Object Encoding in PCEP Messages 


Message formats in this document are expressed using Routing BNF (RBNF) as used in [RFC5440] 
and defined in [RFC5511]. 


6.3.1. Stateful PCEP Messages 


The ASSOCIATION object MAY be carried in the PCUpd, PCRpt, and Path Computation Initiate 
(PCInitiate) messages. 


When carried in a PCRpt message, this object is used to report the association group membership 
pertaining to an LSP to a stateful PCE. The PCRpt message is used for initial State Synchronization 
operations (Section 5.6 of [RFC8231]), as well as whenever the state of the LSP changes. If the LSP 
belongs to an association group, then the associations MUST be included during the State 
Synchronization operations. 


The PCRpt message can also be used to remove an LSP from one or more association groups by 
setting the R flag to 1 in the ASSOCIATION object. 


When an LSP is first reported to the PCE, the PCRpt message MUST include all the association 
groups that it belongs to. Any subsequent PCRpt message SHOULD include only the associations 
that are being modified or removed. 


The PCRpt message is defined in [RFC8231] and updated as shown below: 


<PCRpt Message> ::= <Common Header> 
<state-report-List> 


Where: 
<state-report-List> ::= <state-report>[<state-report-list>] 
<state-report> ::= [<SRP>] 
<LSP> 
[<association-Llist>] 
<path> 
Where: 


<path>::= <intended-path> 
[<actual-attribute-List><actual-path> ] 
<intended-attribute-List> 


<association-list> ::= <ASSOCIATION> [<association-list>] 
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When an LSP is delegated to a stateful PCE, the stateful PCE can create a new association group 
for this LSP or associate it with one or more existing association groups. This is done by including 
the ASSOCIATION object in a PCUpd message. A stateful PCE can also remove a delegated LSP 
from one or more association groups by setting the R flag to 1 in the ASSOCIATION object. 


The PCUpd message SHOULD include the association groups that are being modified or removed. 
There is no need to include associations that remain unchanged. 


The PCUpd message is defined in [RFC8231] and updated as shown below: 


<PCUpd Message> ::= <Common Header> 
<update-request-list> 


Where: 
<update-request-List> ::= <update-request>[<update-request-Llist>] 
<update-request> ::= <SRP> 
<LSP> 
[<association-List>] 
<path> 
Where: 


<path>::= <intended-path><intended-attribute-list> 

<association-list> ::= <ASSOCIATION> [<association-list> ] 
Unless a PCEP speaker wants to delete an association from an LSP or make changes to the 
association, it does not need to include the ASSOCIATION object in future stateful messages. 


A PCE initiating a new LSP can also include the association groups that this LSP belongs to. This is 
done by including the ASSOCIATION object in a PCInitiate message. The PCInitiate message MUST 
include all the association groups that it belongs to. The PCInitiate message is defined in 
[RFC8281] and updated as shown below: 


<PCInitiate Message> ::= <Common Header> 
<PCE-initiated-Lsp-list> 


Where: 
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<PCE-initiated-lsp-lList> ::= <PCE-initiated-lsp-request> 
[<PCE-initiated-Lsp-list>] 
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lLsp-instantiation> | 
<PCE-initiated-Lsp-deletion>) 

<PCE-initiated-Lsp-instantiation> ::= <SRP> 

<LSP> 

[<END-POINTS> ] 

<ERO> 


[<association-Llist>] 
[<attribute-list> ] 


Where: 
<association-list> ::= <ASSOCIATION> [<association-Llist>] 


6.3.2. Request Message 


In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY 
be carried in the PCReq message. 


When carried in a PCReq message, the ASSOCIATION object is used to associate the path 
computation request to an association group. The association (and the other LSPs) should be 
known to the PCE beforehand. These could be operator configured or dynamically learned 
beforehand via stateful PCEP messages. The R flag in the ASSOCIATION object within a PCReq 
message MUST be set to 0 while sending and ignored on receipt. 


The PCReq message is defined in [RFC5440] and updated in [RFC8231]. It is further updated 
below for association groups: 


<PCReq Message>::= <Common Header> 
[<svec-list> ] 
<request-list> 


Where: 
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<svec-list>::= <SVEC>[<svec-list>] 
<request-List>::= <request>[<request-List>] 
<request>::= <RP> 

<END-POINTS> 

[<LSP>] 

[<LSPA> ] 

[<BANDWIDTH> ] 


[<metric-list>] 
[<association-List>] 
[ <RRO>[<BANDWIDTH> ] ] 
[<IRO>] 

[ <LOAD-BALANCING> ]| 


Where: 
<association-list> ::= <ASSOCIATION> [<association-list> ] 


Note that the LSP object MAY be present for the passive stateful PCE mode. 


6.3.3. Reply Message 


In the case of a passive (stateful or stateless) PCE, the ASSOCIATION object is OPTIONAL and MAY 
be carried in the PCRep message with the NO-PATH object. The ASSOCIATION object in the PCRep 
message indicates the association group that caused the PCE to fail to find a path. 


The PCRep message is defined in [RFC5440] and updated in [RFC8231]. It is further updated 


below for association groups: 


<PCRep Message> ::= <Common Header> 
<response-List> 


Where: 


<response-list>: :=<response>[<response-Llist> ] 


<response>: :=<RP> 
[<LSP>] 
[<NO-PATH> ] 
[<association-List>] 
[<attribute-list> ] 
[<path-list>] 


Where: 


<association-list> ::= <ASSOCIATION> [<association-list> ] 
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Note that the LSP object MAY be present for the passive stateful PCE mode. 


6.4. Processing Rules 


Association groups can be operator configured on the necessary PCEP speakers, and the PCEP 
speakers can join the existing association groups. In addition, a PCC or a PCE can create 
association groups dynamically, and the PCEP speaker can also report the associations to its peer 
via PCEP messages. The Operator-configured Associations are created via configurations (where 
all association parameters are manually set) and exist until explicitly removed via 
configurations. The PCEP speaker can add LSPs to these configured associations and provide this 
information via stateful PCEP messages. The dynamic associations are created dynamically by 
the PCEP speaker (where all association parameters are populated dynamically). The association 
group is attached to the LSP state, and the association group exists until there is at least one LSP 
as part of the association. As described in Section 6.1.4, the association parameters are the 
combination of Association Type, Association ID, and Association Source, as well as the optional 
Global Association Source and Extended Association ID TLVs; this combination uniquely 
identifies an association group. The information related to the Association Types encoded via the 
TLVs of a particular Association Type (not described in this document) is the association 
information (Section 6.1.4). 


If a PCEP speaker does not recognize the ASSOCIATION object in the stateful message, it will 
return a PCErr message with Error-Type "Unknown Object" as described in [RFC5440]. In the case 
of a PCReq message, the PCE would react based on the P flag as per [RFC5440]. If a PCEP speaker 
understands the ASSOCIATION object but does not support the Association Type, it MUST return a 
PCErr message with Error-Type 26 "Association Error" and Error-value 1 "Association Type is not 
supported". If any association parameters are invalid in the ASSOCIATION object, the PCEP 
speaker would consider this object malformed and process it as a malformed message [RFC5440]. 
On receiving a PCEP message with an ASSOCIATION object, if a PCEP speaker finds that too many 
LSPs belong to the association group, it MUST return a PCErr message with Error-Type 26 
"Association Error" and Error-value 2 "Too many LSPs in the association group". If a PCEP 
speaker cannot handle a new association, it MUST return a PCErr message with Error-Type 26 
"Association Error" and Error-value 3 "Too many association groups". These numbers MAY be set 
by the operator or chosen based on a local policy. 


If a PCE peer is unwilling or unable to process the ASSOCIATION object in the stateful message, it 
MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant 
procedures described in [RFC5440]. In the case of a PCReq message, the PCE would react based 
on the P flag as per [RFC5440]. On receiving a PCEP message with an ASSOCIATION object, if a 
PCEP speaker could not add the LSP to the association group for any reason, it MUST return a 
PCErr message with Error-Type 26 "Association Error" and Error-value 7 "Cannot join the 
association group". 


If a PCEP speaker receives an ASSOCIATION object for an Operator-configured Association and 
the Association ID is not in the Operator-configured Association Range for the Association Type 
and Association Source, it MUST return a PCErr message with Error-Type 26 "Association Error" 
and Error-value 8 "Association ID not in range". 
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If a PCEP speaker receives an ASSOCIATION object in a PCReq message and the association is not 
known (the association is not configured, was not created dynamically, or was not learned from a 
PCEP peer), it MUST return a PCErr message with Error-Type 26 "Association Error" and Error- 
value 4 "Association unknown". 


If the association information (related to the association group as a whole) received from the 
peer does not match the local operator-configured information, it MUST return a PCErr message 
with Error-Type 26 "Association Error" and Error-value 5 "Operator-configured association 
information mismatch". On receiving association information (related to the association group as 
a whole) that does not match the association information previously received about the same 
association from a peer, it MUST return a PCErr message with Error-Type 26 "Association Error" 
and Error-value 6 "Association information mismatch". Note that information related to each LSP 
within the association as part of the association information TLVs could be different. 


If a PCEP speaker receives an ASSOCIATION object with the R bit set for removal and the 
association group (identified by association parameters) is not known, it MUST return a PCErr 
message with Error-Type 26 "Association Error" and Error-value 4 "Association unknown". 


The dynamic associations are cleared along with the LSP state information as per [RFC8231]. 
When a PCEP session is terminated, after expiry of the State Timeout Interval at the PCC, the LSP 
state associated with that PCEP session is reverted to operator-defined default parameters or 
behaviors. The same procedure is also followed for the association groups. On session 
termination at the PCE, when the LSP state reported by the PCC is cleared, the association groups 
are also cleared. When there are no LSPs in an association group, the association is considered 
empty and thus deleted. 


If the LSP is delegated to another PCE on session failure, the associations (and association 
information) set by the PCE remain intact, unless updated by the new PCE that takes over. 


Upon LSP delegation revocation, the PCC MAY clear the association created by the PCE, but in 
order to avoid traffic loss, it SHOULD perform this action in a make-before-break fashion (same 
as [RFC8231]). 


7. IANA Considerations 


IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <https:// 
www.iana.org/assignments/pcep>. 


7.1. PCEP Object 


The "Path Computation Element Protocol (PCEP) Numbers" registry contains a subregistry called 
"PCEP Objects". IANA has allocated the following code point in the "PCEP Objects" registry. 


Object-Class Value Name Object-Type Reference 


40 ASSOCIATION 0: Reserved RFC 8697 
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Object-Class Value Name Object-Type Reference 
1: IPv4 RFC 8697 
2: IPv6 RFC 8697 


Table 1: PCEP Object 


7.2. PCEP TLV 
IANA has allocated the following code points in the "PCEP TLV Type Indicators" registry. 


Value Meaning Reference 
29 Operator-configured Association Range RFC 8697 
30 Global Association Source RFC 8697 
31 Extended Association ID RFC 8697 


Table 2: PCEP TLV Type Indicators 


IANA has corrected the capitalization in the meaning for value 31 in the above registry to 
"Extended Association ID"; it was previously listed as "Extended Association Id". 


IANA has made a new assignment in the existing "PCEP TLV Type Indicators" registry as follows: 


Value Meaning Reference 

35 ASSOC-Type-List RFC 8697 
Table 3: ASSOC-Type-List PCEP TLV Type 
Indicator 


7.3. Association Flags 


Per this document, IANA has created a subregistry of the "Path Computation Element Protocol 
(PCEP) Numbers" registry for the bits carried in the Flags field of the ASSOCIATION object. The 
subregistry is called "ASSOCIATION Flag Field". New values are assigned by Standards Action 
[RFC8126]. Each bit is tracked with the following qualities: 


e Bit number (counting from bit 0 as the most significant bit) 
e Capability description 
e Defining RFC 


Bit Description Reference 
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Bit Description Reference 


15 R (Removal) RFC 8697 
Table 4: New ASSOCIATION Flag Field 


7.4. Association Type 


Per this document, IANA has created a subregistry of the "Path Computation Element Protocol 
(PCEP) Numbers" registry for the Association Type field of the ASSOCIATION object. The 
subregistry is called "ASSOCIATION Type Field". New values are assigned by Standards Action 
[RFC8126]. Each value is tracked with the following qualities: 


e Type 
e Name 
e Reference 


Type Name Reference 


0 Reserved RFC 8697 
Table 5: New ASSOCIATION Type Field 


Values 2-65535 are Unassigned. Future documents should request the assignment of Association 
Types from this subregistry. 


7.5. PCEP-Error Object 


IANA has allocated the following code points within the "PCEP-ERROR Object Error Types and 
Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry as 
follows: 


Error- Meaning Error-value Reference 

Type 

26 Association 0: Unassigned RFC 8697 

Error 

1: Association Type is not supported RFC 8697 
2: Too many LSPs in the association group RFC 8697 
3: Too many association groups RFC 8697 
4: Association unknown RFC 8697 
5: Operator-configured association RFC 8697 


information mismatch 
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Error- Meaning Error-value Reference 
Type 
6: Association information mismatch RFC 8697 
7: Cannot join the association group RFC 8697 
8: Association ID not in range RFC 8697 


Table 6: PCEP-ERROR Types and Names 


8. Security Considerations 


The security considerations described in [RFC8231] and [RFC5440] apply to the extensions 
described in this document as well. Additional considerations related to a malicious PCEP 
speaker are introduced, as associations could be spoofed and could be used as an attack vector. 
An attacker could attempt to create too many associations in an attempt to load the PCEP peer. 
The PCEP peer responds with a PCErr message as described in Section 6.4. An attacker could 
impact LSP operations by creating bogus associations. Further, association groups could provide 
an adversary with the opportunity to eavesdrop on the relationship between the LSPs. Thus, 
securing the PCEP session using Transport Layer Security (TLS) [RFC8253], as per the 
recommendations and best current practices in [RFC7525], is RECOMMENDED. 


Much of the information carried in the ASSOCIATION object as per this document is not extra 
sensitive. It often reflects information that can also be derived from the LSP database, but the 
association provides a much easier grouping of related LSPs and messages. Implementations and 
operators can, and should, use indirect values in the ASSOCIATION object as a way to hide any 
sensitive business relationships. 


9. Manageability Considerations 


All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to 
PCEP protocol extensions defined in this document. In addition, requirements and considerations 
listed in this section apply. 


9.1. Control of Function and Policy 


A PCE or PCC implementation MUST allow Operator-configured Associations and SHOULD allow 
the setting of the Operator-configured Association Range (Section 3.4) as described in this 
document. 


9.2. Information and Data Models 


The PCEP YANG module is defined in [PCEP-YANG]. In the future, this YANG module should be 
extended or augmented to provide the following additional information related to association 
groups. 
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An implementation SHOULD allow the operator to view the associations configured or created 
dynamically. Future implementations SHOULD allow the viewing of associations reported by 
each peer and the current set of LSPs in the association. 


It might also be useful to find out how many associations for each Association Type currently 
exist and to know how many free Association IDs are available for a particular Association Type 
and source. 


9.3. Liveness Detection and Monitoring 


Mechanisms defined in this document do not imply any new liveness detection and monitoring 
requirements in addition to those already listed in [RFC5440]. 


9.4. Verifying Correct Operation 


Mechanisms defined in this document do not imply any new operation verification requirements 
in addition to those already listed in [RFC5440] and [RFC8231]. 


9.5. Requirements on Other Protocols 


Mechanisms defined in this document do not imply any new requirements on other protocols. 


9.6. Impact on Network Operations 


Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP extensions defined in this 
document. 
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Appendix A. Example of an Operator-Configured Association 
Range 


Consider an Association Type T1 (which allows both dynamic and Operator-configured 
Associations with a default range of <0x1000, Oxffff>). Consider that, because of the needs of the 
network, the PCE needs to create more dynamic associations and would like to change the 
Association Range to <Oxbffe, Oxffff> instead. During PCEP session establishment, the PCE would 
advertise the new range. The PCC could skip advertising, as the default values are used. If a PCC 
is creating a dynamic association (with the PCC as the Association Source), it needs to pick a free 
Association ID for type T1 in the range <0x1, OxOfff>, whereas if a PCE is creating a dynamic 
association (with the PCE as the Association Source), it needs to pick a free Association ID from 
the range <0x1, Oxbffd>. Similarly, if an Operator-configured Association is manually configured 
with the PCC as the Association Source, it should be from the range <0x1000, Oxffff>, whereas if 
the PCE is the Association Source, it should be from the range <Oxhffe, Oxffff>. If the Association 
Source is not a PCEP peer (for example, an NMS), then the default range of <0x1000, Oxffff> is 
considered. 
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